如何在项目中使用 GitFlow 规范开发

之前写过一篇 Git 的操作指南，但发现在工作中，还是需要规范的工作流 - GitFlow

Git 的工作指南

Gitflow 工作流定义了一个围绕项目发布的严格分支模型，不仅包括了 git 功能分支工作流的概念和命令，还为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互

除了使用功能分支，在做准备、维护和记录发布也使用各自的分支

工作方式

Gitflow 工作流仍然用中央仓库作为所有开发者的交互中心，开发者在本地工作并 push 分支到中央仓库中

历史分支

Gitflow 工作流使用 2 个分支来记录项目的历史：

master 分支存储了正式发布的历史保存随时可发布的代码所有的 hotfix 分支都是从 master 分支上拉所有到master的提交都必须要有tag 方便回滚
develop 分支作为功能的集成分支 功能最新最全的分支所有的 feature、release 分支都是从 develop 分支上拉

功能分支 - feature

每个新功能位于一个自己的分支 feature，这样可以 push 到中央仓库以备份和协作。主要是用来开发新的功能

功能分支是使用 develop 分支作为父分支。当新功能完成时，合并回 develop 分支。新功能提交应该从不直接与 master 分支交互

功能分支 + develop 分支就是功能分支工作流的用法

发布分支 - release

一旦 develop 分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从 develop 分支上 fork 一个发布分支，新建的分支用于开始发布循环：做 Bug 修复、文档生成和其它面向发布任务

一旦对外发布的工作都完成了，发布分支合并到 master 分支并分配一个版本号打好 Tag

另外，这些从新建发布分支以来的做的修改要合并回 develop 分支

使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能

发布分支命名常用方法：release-* 或 release/（feature/-20190523 ）

维护分支 - hotfix

维护分支或说是热修复（ hotfix ）分支用于快速给产品发布版本（ production releases ）打补丁，这是唯一可以直接从 master 分支 fork 出来的分支。用于修复线上代码的bug

修复完成，修改应该马上合并回 master 分支和 develop 分支（当前的发布分支），master 分支应该用新的版本号打好 Tag

为 Bug 修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环

命令行操作 Gitflow

首先为 master 分支配套一个 develop 分支，并建好 develop 分支的跟踪分支

git clone xxxx
git checkout -b develop origin/develop

工程师A和工程师B开始开发新功能

他们需要为各自的功能创建相应的分支，新分支基于develop分支：

git checkout -b some-feature develop

用老套路添加提交到各自功能分支上：编辑、暂存、提交：

git status
git add
git commit

工程师A完成功能开发

如果团队使用 Pull Requests，这时候可以发起一个用于合并到 develop 分支。否则她可以直接合并到她本地的 develop 分支后 push 到中央仓库：

git pull origin develop
git checkout develop
git merge some-feature
git push
git branch -d some-feature

工程师A开始准备发布

用一个新的分支来做发布准备，这一步也确定了发布的版本号

git checkout -b release-0.1 develop

这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支

工程师A完成发布

一旦准备好了对外发布，工程师A合并修改到 master 分支和 develop 分支上，删除发布分支

另外，如果工程师A的团队要求 Code Review，这是一个发起 Pull Request 的理想时机

git checkout master
git merge release-0.1
git push
git checkout develop
git merge release-0.1
git push
git branch -d release-0.1

发布分支是作为功能开发（ develop 分支）和对外发布（ master 分支）间的缓冲。只要有合并到 master 分支，就应该打好 Tag 以方便跟踪

git tag -a 0.1 -m "Initial public release" master
git push --tags

最终用户发现 Bug

从 master 分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回 master 分支

git checkout -b issue-#001 master

Fix the bug

git checkout master
git merge issue-#001
git push

维护分支中新加这些重要修改也需要包含到 develop 分支中

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001
git tag -a tag tag名称 master
git push --tags

工程师A回去和工程师B一起做下个发布的新功能开发

Gitflow 操作命令

初始化

git flow init

feature分支相关操作

创建新的feature分支

git flow feature start 分支名称

推送feature分支到远程

git flow feature publish 分支名称

获取feature分支

git flow feature pull origin 分支名称

完成feature

git flow feature finish 分支名称

后续类似

git-flow 工作流程插件

brew install git-flow

一键安装 git-flow，增加一些扩展命令，官方文档可以查看 official documentation

接下来我们就可以很方便的管理分支

比如创建功能分支

git flow init
git flow feature start MYFEATURE
git flow feature publish MYFEATURE
git flow feature finish MYFEATURE